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(57) An automatic transmitting system for use in a 
networked printing system including a first client, sec- 
ond client and server. The automatic transmitting sys- 
tem includes an agent, operatively associated with the 
server, for maintaining information regarding a plurality 
of subsystems associated with a printing machine - the 
agent communicates with both the first and second cli- 
ents. The automatic transmitting system further includes 
a registration system, including the first client, the sec- 
ond client and the agent, for registering the information. 
The information includes a first identifier and a second 
identifier, the first and second identifiers being stored 
with the agent and corresponded with first and second 
sets of information, respectively. In practice, the agent 
transmits the first set of information exclusively to the 
first client when a first event occurs in one or more of 
the plurality of subsystems and transmits a second set 
of information exclusively to the second client when a 
second event occurs in one or more of the plurality of 
subsystems. 
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Description 

The present invention relates generally to a tech- 
nique for monitoring the occurrence of selected events 
in a printing system and more particularly to a networked 
arrangement with a first client, a second client and a 
server in which a packet of information, indicating the 
occurrence of an event, is automatically transmitted by 
the server, over the network, to a selected one of the 
first client and the second client, in response to the event 
occurring. 

Electronic printing systems typically include an in- 
put section, sometimes referred to as an input image 
terminal ("I IT"), a controller, sometimes referred to as 
an electronic subsystem ("ESS") and an output section 
or print engine, sometimes referred to as an image out- 
put terminal ("IO~H). (n one type of electronic printing 
system, manufactured by Xerox® Corporation, known 
as the DocuTech® electronic printing system, a job can 
be inputted to the IIT from, among other sources, a net- 
work or a scanner. 

When a scanner is employed to generate the job, 
image bearing documents are scanned so that the im- 
ages therein are converted to image data for use in mak- 
ing prints. When a network is used to generate the job, 
a stream of data, including various job related instruc- 
tions and image data, expressed in terms of a page de- 
scription language is captured, decomposed and stored 
for printing. As is known, a network job can have its or- 
igin in a remote client, such as a workstation, or a print 
server with a storage device. Jobs provided at the IIT 
may be stored in a memory section, sometimes referred 
to as "electronic precollation memory". 

In one area related to electronic printing, namely 
digital copying, a demand for "multifunctionality" contin- 
ues to grow. As illustrated by the following patent, a mul- 
tifunctional digital copier can assume the form of an ar- 
rangement in which a single electrostatic processing 
printer is coupled with a plurality of different image input 
devices, with such devices being adapted to produce 
image related information for use by the printer. 

Digital copiers typically seek to optimize concurren- 
cy and/or multi-tasking in operation. Xerox' DocuTech® 
optimizes multitasking by using a plurality of processors 
to operate individual services, such as scanning, print- 
ing, storing and decomposing, simultaneously. Accord- 
ingly, in one example, a document can be scanned while 
another document is being printed. Even though this 
sort of multitasking is desirable, it requires a substantial 
amount of both processing capability and storage 
space. A printing system, with an architecture of sub- 
stantially smaller scale than DocuTech®, may be found 
in GB-B-1,531,40. 

As disclosed in US-A-5, 367,635, the pertinent por- 
tions of which are incorporated herein by reference, 
printing-related subsystems may be interconnected via 
a local area network (LAN). 

Local area networks may be interconnected into still 



larger systems spanning a floor or building, a group of 
buildings (campus), a region, or larger areas on up to 
worldwide systems. Each LAN may have a different 
hardware interconnection technology and multiple net- 

5 work protocols. A simple isolated LAN may be adminis- 
tered by individual users. That is, users may change 
equipment, install software, and diagnose problems. 
Large complex LANs or large groups of interconnected 
LANs require "management". "Management" refers to 

10 both a human network manager and software used by 
the human manager. In this application, "management" 
refers to software for managing the overall system, and 
"user" refers to a person using the network management 
software. The user is usually the system administrator. 

is Users can obtain management data and alter manage- 
ment data on the network by using network manage- 
ment software. 

Large network systems are typically dynamic with 
continual requirements for addition and deletion of 

20 equipment, updating of software; and detection and 
analysis of problems. In general, there may be a variety 
of systems from a variety of vendors with a variety of 
system owners. Management software is designed to 
be as general as possible. However, as the overall sys- 

25 tern changes, the user may need information or control 
capabilities not anticipated by the designers of the man- 
agement software. Management software needs to 
have a provision for adding new user defined capabili- 
ties for information gathering and control. 

30 Current network management software is typically 
defined in terms of software objects. A software object 
is a way of organizing data. An object may have a value 
or associated data. An object may have an associated 
executable software process for generating data or for 

35 control purposes. A user can retrieve or alter the data 
associated with an object. Network management ob- 
jects are uniquely identified by object identifiers. 

An agent is software running as a background proc- 
ess on each of the target devices. When a user requests 

40 management data from a device on the network, man- 
agement software will send an object identification in a 
management packet or frame to the target agent. The 
agent will interpret the object identification, retrieve data 
associated with the object identification, and send the 

45 data in a packet back to the user. Sometimes, a corre- 
sponding process may be invoked to retrieve data. 

Current network management agent software is 
typically sold with a hierarchy of fixed predefined ob- 
jects. There are typically no provisions for a user to add 

50 or modify objects. Some management software pro- 
vides "extensible" agents. "Extensible" typically means 
that a user has access to source code for the agent and 
can modify the source code and recompile. Alternative- 
ly, the user may write additional code in a programming 

55 language which requires compilation but may not be re- 
quired to recompile the original agent. In either case, 
writing source code in a programming language and 
compilation of the source code is required. There is a 
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need for users to have the capability to add objects and 
associated processes without having to write code in a 
programming language requiring compilation. 

There are numerous standards organizations which 
are attempting to standardize computer networking. The 
International Organization for Standardization (ISO) has 
provided a general reference framework called the 
Open System Interconnection (OSI) model. The OS! 
model for a network management protocol is called 
Common Management Information Protocol (CMIP). 
CMIP is a common network management protocol in 
Europe. In the United States, a more common network 
management protocol is a related variation of CMIP 
called the Simple Network Management Protocol 
(SNMP) (see Marshall T Rose, The Simple Book, Pren- 
tice-Hall, 1991). 

In the SNMP network management terminology, a 
network management system contains at least one net- 
work management station (NMS), several managed 
nodes, each containing an agent, and a network man- 
agement protocol which is used by the management 
station and the agents to exchange management infor- 
mation. A user can obtain data and alter data on the net- 
work by using network management software on the 
NMS to communicate with agent software in the man- 
aged nodes. 

Software for agents conforming to SNMP standards 
is commercially available. Agent source code is also 
available without charge from universities. For example, 
a source code SNMP development kit (hereinafter re- 
ferred to as the "MIT code'') is available from James R. 
Davin, Advanced Network Architecture Group, M.l.T. 
Laboratory for Computer Science, 545 Technology 
Square, Cambridge, Mass. 02139, U.S.A. 

The SNMP defines a structure for a management 
database (a collection- of objects) called the Manage- 
ment Information Base (MIB). Objects in a Ml B have 
names (OBJECT IDENTIFIERS) and data structures 
(OBJECT TYPES). An object identifier is a sequence of 
non-negative integer values which signify a path 
through a tree structure of numbered branches (called 
sub-identifiers). Each sub-identifier is a non-negative in- 
teger. For example, the object identifier 
1 . 3.6. 1.4.1.11.2.12 identifies an object found by starting 
at the root, moving to the branch with the sub-identifier 
1 , moving to a subordinate branch with the sub-identifier 
3, and so forth. The first 6 levels of this example are 
defined by the standard model. In the example, the 
branch identified by the first five sub-identifiers 
(1.3.6.1.4) is the standard SNMP defined branch called 
"private 0 . The next sub-identifier (1) is for a branch 
(called "enterprises") reserved for vendor specific ob- 
jects. The next label (11) is reserved for Hewlett Pack- 
ard. 

Information is retrieved from an agent by sending a 
SNMP GET or GET-NEXT request with an object iden- 
tification as a parameter. Data associated with an object 
can be altered by sending a SNMP SET request to the 



agent with the object identification as one parameter 
and the data as another parameter. An object which can 
be written to is called a "settable" object. 

The MIT code includes a function (named "misEx- 
5 port() B ) for registering (attaching or grafting) an object 
to the object tree structure. There are 4 parameters as 
follows: 

name: (the object identifier) 
io namelen: (the number of sub-identifiers in the ob- 
ject identifier) 

ops: (a list of 6 routines (corresponding to the oper- 
ations RELEASE, CREATE, DESTROY, and SNMP 
requests GET-NEXT, GET, and SET) which can be 
15 performed on management objects) 

cookie: (a pointer to stored parameters associated 
with the specific object identifier within a data struc- 
ture internal to the agent). 

20 MIB standards evolve as required by the industry. 
Proposed MIB standards start as published requests for 
comments. A MIB format for defining objects is specified 
in Request For Comments number 1212 (hereinafter re- 
ferred to as "RFC 121 2°) and an example MIB standard 

25 using that format is specified in Request For Comments 
1213 (hereinafter referred to as "RFC 1213"). Both are 
available from DDN Network Information Center, SRI In- 
ternational, Room EJ291, 333 Ravenswood Avenue, 
Menlo Park, CA 94025, U.S.A. 

30 The RFC 1212 object-type notation requires a se- 
ries of textual clauses as follows: 

SYNTAX: (examples are "INTEGER" and "OCTET 
STRING") 

35 ACCESS: (choices are: "read-only", "read-write", 
"write-only", and "not-accessible") 
STATUS: (the required choice for status in a com- 
mercial product is "mandatory". In an experimental 
MIB, the word "optional" is allowed.) 

40 DESCRIPTION: (A textual explanation of the object 
delimited by quote marks.) 

In a network printing system, it is believed that de- 
termining, at a client workstation, when an event, e.g. 
45 completion of a print job, has transpired at a remote 
printer is not achieved readily unless, of course, bi-di- 
rectional communication exists between the client and 
the remote printer. In those cases where only unidirec- 
tional communication exists between the client and the 
so remote printer, however, the remote printer cannot 
"speak to" the client directly. In one example, a user can 
query a server, from a workstation, in a Xerox Network 
Service arrangement to determine when a network job 
has completed printing. The server in such arrange- 
rs ment, however, is not configured to automatically notify 
the user, at the workstation, of printing completion. 

There is a need for a technique which avoids the 
problems with conventional approaches which may be 
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satisfactory for the group as a whole, but can create an 
annoyance in certain situations. For example, in a group 
including a first user and a second user, the print job 
belonging to the first user may be completed at a printer 
remote to both users. There is a need for a technique 
which avoids both users receiving a trap or message 
indicating that the job of the first user has been complet- 
ed. Under ideal circumstances,, the second user would 
prefer not to hear about the occurrence of events that 
effect only the first user. Additionally, there is a need for 
a technique which is appropriate for use with a remote 
printer employing a print queue. That is, when the print 
queue is employed, there is a need for a technique 
whereby the network server has a means of knowing 
when printing of a job in the queue is completed. More- 
over, there is a need for a technique which is platform 
independent. It would be desirable to provide a system 
that is platform independent in which a message regard- 
ing the occurrence of an event at a printing machine (or 
any output device) employed by and remote to a group 
of users is transmitted only to the specific recipient af- 
fected by such occurrence. 

In accordance with the present invention, there is 
provided a system for automatically transmitting a set of 
information to a selected one of first and second clients 
in a printing system including a printing machine asso- 
ciated with a plurality of subsystemsand being opera- 
tively coupled with a server, the server communicating 
with both the first client and the second client, via a net- 
work connection, comprising: an agent operatively as- 
sociated with the server, for maintaining information re- 
garding the plurality of subsystems, said agent commu- 
nicating with both the first and second clients; a regis- 
tration system, including the first client, the second client 
and said agent, for registering the information, the infor- 
mation including a first identifier and a second identifier, 
the first and second identifiers being stored with the 
agent and corresponded with first and second sets of 
information, respectively; and said agent transmitting 
the first set of information exclusively to said first client 
when a first event occurs in one or more of the plurality 
of subsystems and transmitting a second set of informa- 
tion exclusively to the second client when a second 
event occurs in one or more of the plurality of subsys- 
tems. 

The present invention further provides a system tor 
informing a client, with a server, that an event associated 
with one of a plurality of print-related functions has oc- 
curred in a printing system, according to claim 7 of the 
appended claims. 

Preferably, the client includes an emitter, communi- 
cating with the identifier generator, for receiving the sec- 
ond identifier portion and creating a job, the job be ex- 
pressed in a page description language and the second 
identifier portion being embedded in the Job. 

Preferably, the job includes a comment section and 
the second identifier portion is disposed in the comment 
section. 



The system preferably includes means for transmit- 
ting the job to the server where the job is interpreted for 
purposes of parsing the page description language de- 
scription to thereby obtain a plurality of data structures, 
5 wherein during said parsing the second identifier portion 
is stripped from the comment section and placed in a 
data storage area. 

In one embodiment, the job is a first job, the process 
means is a first process means, the event is a first event, 
io and a second resultant identifier is corresponded, in the 
agent with a second packet of information indicating 
that a second event, associated with another one of the 
plurality of print-related functions, has occurred, where- 
in: said source provides a third identifier portion; said 
*s emitter creates a second job, the job being expressed 
in page description language and including the third 
identifier, the third identifier being stored in said storage 
area; said informing system includes a second process, 
associated with another one of the print-related func- 
tions, for conveying the third identifier to said agent 
when the second event occurs; said agent combining 
the third identifier with the first identifier to form the sec- 
ond resultant identifier when the second event occurs; 
said agent transmits the second packet of information 
to the client; in response to receiving the second packet 
packet of information, the user is informed, by the client, 
of the occurrence of the second event by reference to 
the second packet of information. 

Preferably, the job comprises a print job and the 
event comprises a completion of a printing of the print 
job, wherein, in response to printing the print job, the 
first and second identifier portions are combined and 
transmitted to the client for informing the user that the 
printing of the print job has occurred. 

In accordance with another aspect of the invention, 
there is provided a method of informing a client with an 
agent of the occurrence of an event in a printing system, 
including a server communicating with the client by way 
of a network connection, the server including the agent, 
at which a first identifier portion is stored, wherein the 
agent is apprised of an occurrence of an event and the 
event is associated with a function of the printing sys- 
tem, comprising: providing a second identifier portion to 
the server; conveying the second identifier portion to the 
agent when the event occurs; combining the second 
identifier portion and the first identifier portion, with the 
agent to form a resultant identifier, the resultant identi- 
fier corresponding with a packet of information indicat- 
ing that the event has occurred; transmitting the packet 
of information to the client; and in response to receiving 
the packet of information, informing the user of the oc- 
currence of the event by reference to the packet of in- 
formation. 

The method preferably further comprises generat- 
ing the second identifier portion with the client Prefer- 
ably, the generating step includes embedding the sec- 
ond identifier portion in a job expressed in a page de- 
scription language. 
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Preferably, the client includes an emitter communi- 
cating with an identifier generator, wherein said embed- 
ding includes communicating the second identifier por- 
tion from the identifier generator to the emitter so that 
the print driver embeds the second identifier portion in 
the job. 

Preferably, the job includes a comment section, 
wherein said embedding includes writing the second 
identifier portion into the comment section. 

The method preferably further comprises: transmit- 
ting the job to the server; parsing the job, at the server, 
to strip the second identifier from the comment section; 
and placing the second identifier in a data storage area. 

Preferably, the server includes a process for man- 
aging a printing system function and the process com- 
municates with the agent, wherein said conveying in- 
cludes obtaining the second identifier portion from a da- 
ta storage area, with the process, and providing the sec- 
ond identifier portion to the agent for combination with 
the first identifier portion. 

Preferably, the second identifier portion is associat- 
ed with a print job, the print job is provided to the server 
for marking with a printing machine and the event com- 
prises a completion of the marking of the print job, 
wherein said informing comprises informing the user of 
the completion of the print job. 

Preferably, the resultant identifier comprises an ob- 
ject identifier and the method further comprises: config- 
uring the agent with simple network management pro- 
tocol software such that the object identifier is opera- 
tive^ linked with a trap; and automatically transmitting 
the trap to the client when the event occurs. 

The invention further provides a method of automat- 
ically transmitting a packet of information to a selected 
one of first and second clients in a printing system, ac- 
cording to claim 10 of the appended claims. 

The method preferably further comprises: generat- 
ing a print job expressed in a page description language 
at the first client; and embedding the first identifier in the 
page description language of the print job. 

The method preferably further comprises transmit- 
ting the print job from the first client to the server and, 
at the server stripping the first identifier from the page 
description language of the print job. 

Preferably, the server includes a print process for 
managing a function of a print job, the first identifier is 
associated with the print job and the first event compris- 
es a completion of the print job, further comprising trans- 
mitting the first identifier from a data store, associated 
with the server, to the agent, with the print process, when 
the first event occurs. 

Preferably, each of the first identifier and second 
identifier include a first identifier portion and a second 
identifier portion and the method further comprises: 
combining the first identifier portion of the first client with 
one of the second identifier portions when the first event 
occurs and the first identifier portion of the second client 
with one of the second identifier portions when the sec- 
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ond event occurs. 

Preferably, the first identifier is part of a first object 
identifier and the second identifier is part of a second 
object identifier, further comprising configuring the 

s agent with simple network management protocol soft- 
ware such that the first object identifier is corresponded 
with a first trap and the second object identifier is corre- 
sponded with a second trap, the first trap and the second 
trap comprising the first packet of information and the 

10 second packet of information, respectively. 

These and other aspects of the invention will be- 
come apparent from the following description, the de- 
scription being used to illustrate a preferred embodi- 
ment of the invention when read in conjunction with the 

is accompanying drawings, in which: 

Figure 1 is a block diagram depicting a multifunc- 
tional, network adaptive printing machine; 
Figure 2 is a block diagram of a video control mod- 
20 ule for the printing machine of Figure 1 ; 

Figure 3 is a block diagram of a transfer module 
used in conjunction with the printing machine of Fig- 
ure 2; 

Figure 4 is a block diagram of a facsimile card used 
25 jn conjunction with the printing machine of Figure 2; 

Figure 5 is a block diagram of a network controller 
for the printing machine of Figure 1; 
Figure 6 is a schematic diagram of a LAN worksta- 
tion employed in accordance with one embodiment 
30 of the invention; 

Figure 7 is a flow diagram of the technique for gen- 
erating a job in an embodiment of the present in- 
vention; 

Figure 8 is a schematic diagram showing the differ- 
35 ent software elements of a print service employed 
in accordance with the invention; 
Figures 9 and 10 are flow diagrams illustrating the 
techniques for storing a job OID in a server, in ac- 
cordance with the invention; and 
40 Figure 11 is a flow diagram of the steps involved in 
informing a single client of the occurrence of an 
event at a remote printer. 

Referring to Figure 1, a multifunctional, network 
4S adaptive printing system is designated by the numeral 
10. The printing system 10 includes a printing machine 
12 operatively coupled with a network service module 
14. The printing machine 12 includes an electronic sub- 
system 1 6, referred to as a video control module (VCM), 
so communicating with a scanner 18 and a printer 20. In 
one example, the VCM 16, which will be described in 
further detail below, coordinates the operation of the 
scanner and printer in a digital copying arrangement. In 
a digital copying arrangement, the scanner 1 8 (also re- 
55 ferred to as image input terminal (I IT)) reads an image 
on an original document by using a CCD full width array 
and converts analog video signals, as gathered, into dig- 
ital signals. In turn, an image processing system 22 (Fig- 
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ure 2), associated with the scanner 18, executes signal 
correction and the like, converts the corrected signals 
into multi-level signals (e.g. binary signals), compresses 
the multi-level signals and preferably stores the same 
in electronic precollation (EPC) memory 24. 

Referring again to Figure 1 , the printer 20 (also re- 
ferred to as image output terminal (IOT)) preferably in- 
cludes a xerographic print engine. In one example, the 
print engine has a multi-pitch belt (not shown) which is 
written on with an imaging source, such as a synchro- 
nous source (e.g. laser raster output scanning device) 
or an asynchronous source (e.g. LED print bar). In a 
printing context, the multi-level image data is read out 
of the EPC memory 24 (Figure 2) while the imaging 
source is turned on and off, in accordance with the im- 
age data, forming a latent image on the photoreceptor. 
In turn, the latent image is developed with, for example, 
a hybrid jumping development technique and trans- 
ferred to a print media sheet. Upon fusing the resulting 
print, it may be inverted for duplexing or simply output- 
ted. It will be appreciated by those skilled in the art that 
the printer can assume other forms besides a xero- 
graphic print engine without altering the concept upon 
which the disclosed embodiment is based. For example, 
the printing system 1 0 could be implemented with a ther- 
mal ink jet or ionographic printer. 

Referring specifically to Figure 2, the VCM 1 6 is dis- 
cussed in further detail. The VCM 16 includes a video 
bus (VBus) 28 with which various I/O, data transfer and 
storage components communicate. Preferably the 
VBus is a high speed, 32 bit data burst transfer bus 
which is expandable to 64 bit. The 32 bit implementation 
has a sustainable maximum bandwidth of approximate- 
ly 60 MBytes/sec: In one example, the bandwidth of the 
VBus is as high as 100 MBytes/sec. 

The storage components of the VCM reside in the 
EPC memory section 30 and the mass memory section 
32. The EPC memory section includes the EPC memory 
24, the EPC memory being coupled with the VBus by 
way of a DRAM controller 33. The EPC memory, which 
is preferably DRAM, provides expansion of up to 64 
MBytes, by way of two high density 32 bit SIMM mod- 
ules. The mass memory section 32 includes a SCSI 
hard drive device 34 coupled to the VBus by way of a 
transfer module 36a. As will appear, other I/O and 
processing components are coupled respectively to the 
VBus by way of transfer modules 36. It will be appreci- 
ated that other devices (e.g. a workstation) could be 
coupled to the VBus by way the transfer module 36a 
through use of a suitable interface and a SCSI line. 

Referring to Figure 3, the structure of one of the 
transfer modules 36 is discussed in further detail. The 
illustrated transfer module of Figure 3 includes a packet 
buffer 38, a VBus interface 40 and DMA transfer unit 
42 . The transfer module 36, which was designed with 
"VHSIC" Hardware Description Language (VHDL), is a 
programmable arrangement permitting packets of im- 
age data to be transmitted along the VBus at a relatively 
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high transfer rate. In particular, the packet buffer is pro- 
grammable so that the segment or packet can be varied 
according to the available bandwidth of the VBus. In one 
example, the packet buffer can programmed to handle 
5 packets of up to 64 Bytes Preferably, the packet size 
would be reduced for times when the VBus is relatively 
busy and increased for times when activity on the bus 
is relatively low. 

Adjustment of the packet size is achieved with the 

10 VBus interface 40 and a system controller 44 (Figure 5). 
Essentially, the VBus interface is an arrangement of log- 
ical components, including, among others, address 
counters, decoders and state machines, which provides 
the transfer module with a selected degree of intelli- 

15 gence. The interface 40 communicates with the system 
controller to keep track of desired packet size and, in 
turn, this knowledge is used to adjust the packet size of 
the packet buffer 38, in accordance with bus conditions. 
That is, the controller, in view of its knowledge regarding 

20 conditions on the VBus 28, passes directives to the in- 
terface 40 so that the interface can adjust packet size 
accordingly. Further discussion regarding operation of 
the transfer module 36 is provided below 

More particularly, each imageThe DMA transfer unit 

2S employs a conventional DMA transfer strategy to trans- 
fer the packets. In other words, the beginning and end 
addresses of the packet are used by the transfer unit in 
implementing a given transfer. When a transfer is com- 
plete, the interface 40 transmits a signal back to the sys- 

30 tern controller 44 so that further information, such as de- 
sired packet size and address designations, can be ob- 
tained. 

Referring to Figures 1 and 2, three I/O components 
are shown as being coupled operatively to the VBus 28, 
35 namely a FAX module 48, the scanner or I IT 18, and the 
printer or IOT 20; however, it should be recognized that 
a wide variety of components could be coupled to the 
VBus by way an expansion slot 50. Referring to Figure 
4, an implementation for the FAX module, which is cou- 
40 pied to the VBus 28 by way of transfer module 36b, is 
discussed in further detail. In the preferred embodiment, 
a facsimile device (FAX) 51 includes a chain of compo- 
nents, namely a section 52 for performing Xerox adap- 
tive compression/decompression, a section 54 for scal- 
es ing compressed image data, a section 56 for converting 
compressed image data to or from CCITT format, and 
a modem 58, preferably manufactured by Rockwell Cor- 
poration, for transmitting CCITT formatted data from or 
to a telephone, by way of a conventional communication 
so line. 

Referring still to Figure 4, each of the sections 52, 
54 and 56 as well as modem 58 are coupled with the 
transfer module 36b by way of a control line 60. This 
permits transfers to be made to and from the FAX mod- 
55 ule 48 without involving a processor. As should be un- 
derstood, the transfer module 36b can serve as a master 
or slave for the FAX module in that the transfer module 
can provide image data to the FAX for purposes of trans- 
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mission or receive an incoming FAX. In operation, the 
transfer module 36b reacts to the FAX module in the 
same manner that it would react to any other I/O com- 
ponent. For example, to transmit a FAX job, the transfer 
module 36b feeds packets to the section 52 through use 
of the DMA transfer unit 42 and, once a packet is fed, 
the transfer module transmits an interrupt signal to the 
system processor 44 requesting another packet. In one 
embodiment, two packets are maintained in the packet 
buffer 38 so that "ping-ponging" can occur between the 
two packets. In this way, the transfer module 36b does 
not run out of image data even when the controller can- 
not get back to it immediately upon receiving an interrupt 
signal. 

Referring again to Figure 2, the IIT 18 and IOT 20 
are operatively coupled to the VBus 28 by of transfer 
modules 36c and 36d. Additionally, the IIT 18 and the 
IOT 20 are operatively coupled with a compressor 62 
and a decompressor 64, respectively. The compressor 
and decompressor are preferably provided by way of a 
single module that employs Xerox adaptive compres- 
sion devices. Xerox adaptive compression devices have 
been used for compression/decompression operations 
by Xerox Corporation in its DocuTech® printing system. 
In practice, at least some of the functionality of the trans- 
fer modules is provided by way of a 3 channel DVMA 
device, which device provides local arbitration for the 
compression/decompression module. 

As further illustrated by Figure 2, the scanner 18, 
which includes the image processing section 22, is cou- 
pled with an annotate/merge module 66. Preferably the 
image processing section includes one or more dedicat- 
ed processors programmed to perform various desired 
functions, such as image enhancement, thresholding/ 
screening, rotation, resolution conversion and TRC ad- 
justment. The selective activation of each of these func- 
tions can be coordinated by a group of image processing 
control registers, the registers being programmed by the 
system controller 44. Preferably, the functions are ar- 
ranged along a "pipeline" in which image data is inputted 
to one end of the pipe, and image processed image data 
is outputted at the other end of the pipe. To facilitate 
throughput, transfer module 36e is positioned at one 
end of the image processing section 22 and transfer 
module 36c is positioned at another end of the section 
22. As will appear, positioning of transfer modules 36c 
and 36e in this manner greatly facilitates the concurren- 
cy of a loopback process. 

Referring still to Figure 2, arbitration of the various 
bus masters of the VCM 16 is implemented by way of a 
VBus arbiter 70 disposed in a VBus arbiter/bus gateway 
71 . The arbiter determines which bus master (e.g. FAX 
module, Scanner, Printer, SCSI Hard Drive, EPC Mem- 
ory or Network Service Component) can access the 
VBus at one given time. The arbiter is made up of two 
main sections and a third control section. The first sec- 
tion, i.e., the "Hi-Pass" section, receives input bus re- 
quests and current priority selection, and outputs a grant 
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corresponding to the highest priority request pending. 
The current priority selection input is the output from the 
second section of the arbiter and is referred to as "Pri- 
ority Select". This section implements priority rotation 

s and selection algorithm. At any given moment, the out- 
put of the logic for priority select determines the order 
in which pending requests will be serviced. The input to 
Priority Select is a register which holds an initial place- 
ment of devices on a priority chain. On servicing re- 

10 quests, this logic moves the devices up and down the 
priority chain thereby selecting the position of a device's 
next request. Control logic synchronizes the tasks of the 
Hi-Pass and the Priority Select by monitoring signals re- 
garding request/grant activity. It also prevents the pos- 

ts sibility of race conditions. 

Referring to Figure 5, the network service module 
14 is discussed in further detail. As will be recognized 
by those skilled in the art the architecture of the network 
service module is similar to that of a known "PC clone". 

20 More particularly, in the preferred embodiment, the con- 
troller 44, which preferably assumes the form of a 
SPARC processor, manufactured by Sun Microsystems, 
Inc., is coupled with a standard SBus 72. In the illustrat- 
ed embodiment of Figure 5, a host memory 74, which 

25 preferably assumes the form of DRAM, and a SCSI disk 
drive device 76 are coupled operatively to the SBus 72. 
While not shown in Figure 5, a storage or I/O device 
could be coupled with the SBus with a suitable interface 
chip. As further shown in Figure 5, the SBus is coupled 

30 with a network 78 by way of an appropriate network in- 
terface 80. In one example, the network interface in- 
cludes all of the hardware and software necessary to 
relate the hardware/software components of the control- 
ler 44 with the hardware/software components of the 

35 network 78. For instance, to interface various protocols 
between the network service modu le 1 4 and the network 
78, the network interface could be provided with, among 
other software, Netware® from Novell Corp. 

In one example, the network 78 includes a client, 

40 such as a workstation 81 with an emitter or driver 84. In 
operation, a user may generate a job including a plurality 
of electronic pages and a set of processing instructions. 
In turn, the job is converted, with the emitter, into a rep- 
resentation written in a page description language, such 

45 as PostScript. The job is then transmitted to the control- 
ler 44 where it is interpreted with a decomposer, such 
as one provided by Adobe Corporation. Some of the 
principles underlying the concept of interpreting a PDL 
job are provided in US-A-5,493,634 and US-A- 

50 5,226 : 112. Further details regarding a technique for 
generating a job in a PDL may be obtained by reference 
to PostScript® Language Reference Manual , Second 
Edition, Addison -Wesley Publishing Co., 1990. 

Referring again to Figure 2 f the network service 

55 module 1 4 is coupled with the VCM 1 6 via a bus gateway 
88 of the VBus arbiter/bus gateway 71 . In one example, 
the bus gateway comprises a field programmable gate 
array provided by XI LI NX corporation. The bus gateway 
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device provides the interface between the host SBus 
and the VCM VBus. It provides VBus address transla- 
tion for accesses to address spaces in the VBus real 
address range, and passes a virtual address to the host 
SBus for virtual addresses in the host address range. A 
DMA channel for memory to memory transfers is also 
implemented in the bus gateway Among other things, 
the bus gateway provides seamless access between 
the VBus and SBus, and decodes virtual addresses 
from bus masters, such as one of the transfer modules 
36, so that an identifier can be obtained from a corre- 
sponding slave component. It will be appreciated by 
those skilled in the art that many components of the 
printing system 10 are implemented in the form of a sin- 
gle ASIC. 

Referring to Figures 2, 3 and 5, further discussion 
regarding DMA transfer of each of the transler modules 
36 is provided. In particular, in one example, the images 
of a job are stored in the host memory 74 as a series of 
blocks. Preferably, each block comprises a plurality of 
packets. In operation, one of the transfer modules 36 is 
provided, by the controller 44, with the beginning ad- 
dress of a block and the size of the block. In turn, for 
that block, the transfer module 36 effects a packet tran- 
fer and increments/decrements a counter. This proce- 
dure is repeated for each packet of the block until the 
interface 40 determines, by reference to the counter, 
that the last packet of the block has been transferred. 
Typically, for each stored image, several blocks are 
transferred, in a packet-by-packet manner, as described 
immediately above. 

Referring to FIG. 6, one of the workstations 81 is 
described in further detail, in particular, each worksta- 
tion 81 includes the emitter 84 which facilitates genera- 
tion of a job and communicates with a print manager 
100, As is known, the emitter 84 obtains input from a 
user and converts the same into a page description lan- 
guage, such as PCL 5 or Post Script. In one embodi- 
ment, the emitter is produced by Phoenix Corporation. 
Preferably, the print manager 100 is a process capable 
of receiving a job and spooling it with a mass memory 
section (e.g. disk drive device) 102. 

As discussed in further detail below, a spooled job 
is communicated to a local area network by way of a line 
printer (LPT) port 104. Jobs are transported across the 
network by way of a transport provider 106 which pref- 
erably employs either UDP or IPX protocols. The former 
protocol is based on TCP/IP and the latter protocol is 
provided by way of Novell Corporation. 

An event handling system 108 is provided to deter- 
mine when selected events in the printing system 10 
have occurred. The event handling system includes one 
or more applications 110, an event handling subsystem 
112 and a simple network management protocol 
(SNMP) subsystem 114. While the workstation 81 may 
include multiple applications 110 for handling various 
tasks associated with monitoring event occurrence with- 
in the printing system, hereinafter, for purposes of con- 



venience, only one application for performing the vari- 
ous tasks associated with event handling will be refer- 
enced. The event handling application 110 communi- 
cates with the event handling subsystem 112 which 
s event handling subsystem communicates with the emit- 
ter 84 by way of the print manager 100 and is provided 
with two major responsibilities, each of which responsi- 
bilities will be discussed in further detail below. The 
SNMP subsystem, which communicates with the event 

10 handling subsystem, serves to encode and decode 
packets of information provided in terms of SNMP. 

Referring to FIG. 7, an approach for generating a 
Job, which employs SNMP to manage event handling, 
is provided. Initially, at step 1 1 8 a job is developed at the 

15 emitter 84 in response to appropriate input by the user. 
In some cases, a job need not be developed in that it 
already resides on a portable medium. When this is the 
case, the job is provided to the server. Assuming that 
job development is required, at step 120 it is determined 

20 whether the workstation provides event handling. For 
those circumstances in which event handling is not pro- 
vided, the job is, via step 122, provided without an iden- 
tifier. In the illustrated embodiment of FIG. 7, an identi- 
fier comprises an object identifier (OID) Suffix, i.e. a por- 

25 tion of an OID of the type used in SNMP communication. 

Preferably, event handling is provided , in the work- 
station 81, by default, therefore a unique network OID 
suffix is communicated to the print manager 100 (step 
1 24) from the event handling subsystem 1 1 2. In one ex- 

30 ample, the OID suffix is based on a client address or 
ethernet card identifier. It should be appreciated, that 
more than one OID suffix could be obtained by the print 
manager in order to obtain information about the occur- 
rence of multiple events in the printing system. For ease 

35 of discussion, it will be assumed that one OID suffix is 
obtained and that that OID suffix relates to an event in 
which a developed job is outputted at an output device. 
Nonetheless, the event to which the OID suffix pertains 
could be one of many events associated with the printing 

40 system. With the OID suffix in hand, the emitter 84 gen- 
erates the job in terms of a PDL description (step 126), 
which PDL description will include a comment section 
of the type disclosed in US-A-5, 130,806. Per step 128, 
the emitter 84 embeds the OID suffix into the comment 

45 section of the PDL description and transmits a job to the 
print manager 1 00 (step 1 30) for spooling of the job (step 
132) in the mass memory 102. 

Referring back to step 120, the event handling sys- 
tem performs certain functions in conjunction with the 

so development of the job. More particularly, the applica- 
tion 110 initiates a "listening routine" at step 1 36 and the 
event handling subsystem 112 registers the OID suffix 
(step 1 38) at a print service 140 (FIG. 8). Referring now 
to step 142 and Figure 6 when a job is ready for trans- 

55 mission from the client workstation 81 to the server 1 40, 
the job is transmitted to the service 140, by way of step 
144, in the following manner: 

When submitting the job through the emitter 84 
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(which is preferably a windows print driver), the emitter 
submits the job back to an operating system of the work- 
station 81 which then sends the job through the LPT port 
104. Since the LPT port is redirected to a networked 
printer, of the type used in printing system 1 0 (Figure 1 ), 
the job is ultimately submitted to networked printer 20. 
The emitter software, however, has no knowledge of this 
redirection and has no direct contact with the printer 20. 
As will appear from the discussion below, through use 
of SNMP traps, the client workstation 81 is able to obtain 
information about the occurrence of events in the print- 
ing system even though communication between the 
workstation and the print server is not, in conventional 
terms, viewed as bi-directional. 

In practice, the job is transmitted across the network 
to the network module 14 for interpretation at the print 
server 140. Preferably, the print service 140 is main- 
tained in one of the memory sections 74 or 76 (FIG. 5). 
In one example of operation, the print service 140 is 
transferred from disk 76 to system memory 74. As 
shown in FIG. 8, the print service 140 includes a pre- 
parser 1 48 for parsing the various image components 
of a job. The structure and function of the preparser 1 48 
is discussed in further detail in US-A-5,493,634. As fur- 
ther discussed in the Bonk application, the preparser 
148 would be responsible for stripping the OID suffix 
from the PDL description of the job for storage in a doc- 
ument management section 150. It will be appreciated 
that the print service 140 includes other interpretation 
components, such as a process for binding fonts, which 
are not shown in the FIG. 8. Nonetheless, the compo- 
nents necessary to achieve interpretation of a PDL file 
are known to those skilled in the art and can be obtained 
through use of conventional interpretive schemes such 
as those schemes provided, among others, Phoenix, 
Adobe Corporation or Hewlett-Packard Corporation. 

It is contemplated that the print service 140 will pref- 
erably employ an implementation known as the ISO 
document processing architecture (DPA) standard as 
envisioned by ISO/lEC 10175. The DPA has its origin in 
the Palladium print system which is a distributed print 
system developed at MIT/Project Athena with the par- 
ticipation of Digital Equipment Corporation, Internation- 
al Business Machines and Hewlett-Packard. The "Pal- 
ladium Design Document" a publication of the Massa- 
chusetts Institute of Technology, published on June, 
1991, provides a detailed discussion of the ISO DPA. 
The Palladium print system is based on a two level cli- 
ent-server model Both Print Spooler and Printer Super- 
visor act as servers. The Print Spooler also acts as a 
client to the Printer Supervisor. The Print Client normally 
uses the Print Spooler as its server but may use the 
Printer Supervisor directly. Remote Procedure Calls are 
used for communications between the clients and serv- 
ers. Each Printer has its own dedicated Printer Super- 
visor which communicates data and control information 
with the printer in whatever way is appropriate for that 
type of printer. A name service is used to find printer 
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services for users and to find servers for system man- 
agers. There is no design limit to the number of servers 
that may be installed on a machine. 

A Print Client is a client acting as the user's agent 

5 that accepts commands, submits requests to print serv- 
ices, receives responses, generates per-user local job 
numbers, and remembers for each user where the jobs 
have been submitted. A Print Spooler is a server that 
accepts Palladium operations from Print Clients using a 

10 DCE RPC and schedules print jobs on its Printer Super- 
visors. When the Spooler communicates with the Printer 
Supervisor, it uses the Palladium operations with the 
DCE RPC as well. In this case, the Print Spooler is the 
client and the Printer Supervisor is the server. 

is A Printer Supervisor accepts requests from clients 
(Print Spoolers) to print a job on its Physical Printer If 
the code is multi-threaded, each thread is considered a 
Printer Supervisor and controls its own Physical Printer. 
Usually, a Printer Supervisor registers itself with a 

20 Spooler when it starts and is under the Spooler's control. 
However, a Printer Supervisor can be brought up in 
"stand-alone" mode, in which it does not register itself 
with a Spooler and accepts print jobs directly from Print 
Clients. In this case, the Printer Supervisor is a server 

25 acting as a Spooler without any queuing or job sched- 
uling. 

A Physical Printer is an actual piece of hardware 
that has its own Printer Supervisor controlling it. A 
Queue contains jobs watting to be printed. When a 

30 Physical Printer finishes or nearly finishes a job, its 
Printer Supervisor indicates to the Spooler its readiness 
to accept another print job. The Spooler scans the 
queues that feed the Physical Printer and a scheduling 
algorithm selects the next job and assigns that job to 

35 that Physical Printer by submitting the print job to the 
Print Supervisor using an ISO DPA Print operation. A 
Logical Printer is the abstract entity that users specify 
to indicate where their job is to be printed and/or what 
characteristics their job has. Each logical printer has de- 

40 fault attributes that the server supplies for those at- 
tributes that neither the user nor his Print Client has sup- 
plied. The Spooler may assign a print job to one or more 
Queues based on the specified Logical Printer, depend- 
ing on the scheduling policy as established by its system 

45 administrator. In other words, a Logical Printer feeds 
one or more Queues; each Queue feeds one or more 
Physical Printers as established by the system admin- 
istrator of the Spooler. 

Referring still to FIG. 8, attributes of the developed 

50 job are maintained in a data store 1 52, and management 
of that data store, in other words, access to information 
in the data store, is provided by a document manager 
154. As shown in FIG. 8; the document management 
system 1 50 is in communication with a subsystem proc- 

55 ess section 1 56, the section 1 56 including processes for, 
among other things, imaging, marking, finishing and di- 
agnostics. In practice, a subsystem process is respon- 
sible for not only performing a certain function within the 
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printing system, but for providing information about the 
occurrence of an event associated with that particular 
function. Consequently, a subsystem process, such as 
marking, would provide information about, among other 
things, the level of toner or ink available in any given 
printer or when a job has completed printing. Other sub- 
- system processes such as diagnostics could inform the 
user of events such as a jam in a paper path of one of 
the available printers. Yet other subsystem processes, 
such as a FAX service subsystem could provide infor- 
mation regarding the completion or transmission of a 
FAX. As will appear, the presently disclosed embodi- 
ment is pertinent for use with a large variety of document 
processing related events. 

The subsystem process section 156 communicate 
with an agent 158, the agent 158 including a configura- 
tion table 160. Preferably, the agent 158 includes avail- 
able SNMP (version 2) software and the configuration 
table is provided in accordance with such software. As 
will be appreciated by those skilled in the art, the con- 
figuration table (or tables) corresponds OlDs or "traps", 
with respective managers (clients) on the network. 
While the configuration table 160 preferably includes a 
plurality of tables, provided in accordance with an avail- 
able SNMP (version 2) package, in other examples the 
table could simply comprise a look-up table associating 
the traps with the respective managers. Additionally, in 
the preferred embodiment, the agent 158 follows SNMP 
rules to access and obtain selected information from the 
configuration table(s). 

Referring to FIGS. 9 and 1 0 an approach for storing 
a job OID portion in the server 1 40 is shown. By way of 
step 164, a job is conveyed to the preparser 148 (FIG. 
8) via a connectivity layer and interpretation of the job 
is begun. During such interpretation (step 166), a job 
OID portion is stripped from the comments section of 
the PDL description of the job. Referring specifically to 
FIG. 10, it will be recognized that, in the illustrated em- 
bodiment, a job OID includes a "prefix OID" and "suffix 
OID". In one example of operation, the prefix OID is 
maintained at the agent 158, while the suffix OID is pro- 
vided to the print manager 100 (FIGS. 6 and 7), by the 
event handling subsystem 112. In accordance with the 
DPA standard discussed above, a set of job attributes 
is generated for the incoming job, at step 168, and the 
suffix OID is associated with one of the job attributes. In 
turn, at step 170, the job attributes generated in step 
168 are, via 170, stored in the data storage 152 (FIG. 8). 

Referring to FIGS. 6, 8 and 10, an approach for us- 
ing SNMP (version 2) to inform a single client of the oc- 
currence of an event at a printer remote to the single 
client is discussed. At step 174, (FIG. 11), an event oc- 
curs and the subsystem process associated with the 
event (FIG. 8) detects the occurrence of the event, at 
step 176, and requests a suitable OID suffix from the 
document manager ("DM") 154, the suffix specifically 
being associated with a trap indicating that the event 
has occurred. In response to the request from the sub- 



system process, the document manager retrieves the 
appropriate OID suffix from the data store 152 (step 178) 
and transfers it to the subsystem process of section 1 56 
that has requested it. Upon receiving the OID suffix, the 

s receiving subsystem process transmits the OID suffix, 
at step 1 80, to the agent 1 58. 1 n turn, the agent 1 58 com- 
bines the suffix with a corresponding prefix to form an 
OID resultant or trap (step 182). As will be appreciated 
by those skilled in the art, the prefix OID includes various 

10 branches and leaves which, in combination, serve as an 
OID for a broad group of users on the network. It is the 
addition of the suffix OlDtothe prefix OID which makes 
the OID resultant particular to a single client on the net- 
work. 

15 Preferably, the trap is obtained through use of con- 
ventional SNMP (version 2) software; however, when 
the OlDs are corresponded with traps by way of a look- 
up table, the more complex approach contemplated by 
SNMP (version 2) need not be followed. With the trap 

20 obtained in step 182, a message, assuming the form of 
a "packet" is transmitted from the agent, across the net- 
work to the SNMP subsystem 114 (FIG. 6) of the work- 
station 81. In turn, the SNMP subsystem decodes the 
contents of the packet, at step 1 88, and conveys the de- 

25 coded information to the application 1 1 0. Preferably, the 
application 110 cooperates with a user interface of the 
workstation 81 (not shown) in such a way that the user 
of workstation 81 is provided with the essential informa- 
tion of the packet as soon as possible. Referring to step 

30 1 90, when the application 110 (or emitter 84) closes, a 
cleanup routine is called in an event handling library of 
event handling subsystem 112. In one example, the 
cleanup routine cleans up the entries in local and remote 
configuration databases, thus disabling traps between 

35 the two entities. If this cleanup cannot happen (as in the 
case of a crash), the entries will be cleaned up when 
each side is reset. Until such time, spurious traps gen- 
erated by the service 140 (FIG. 8) will be ignored by the 
client. 

40 Referring again to FIG. 10, it should be understood 
that in one embodiment the event handling subsystem 
112 provides the print imager 100 with the same suffix 
OID for each job to be developed at the emitter 84. Con- 
sequently, if a user sends many jobs from the worksta- 

45 tion 81 of FIG. 6 to the print service 140 of FIG. 8, in a 
short period of time, upon receiving a trap subsequently 
it may not be clear to the user to which job that trap ap- 
plies. Accordingly, it has been found that when many 
jobs are to be transmitted by the user it is advisable to 

50 configure the suffix OID with an additional portion 194 
so that a specific OID : which corresponds to a particular 
job, is provided. As will be recognized, a trap corre- 
sponded with the specific OID would permit identifica- 
tion of a particular trap as being associated with a unique fk 

ss job. / 
Numerous features of the above-disclosed embod- 
iment will be appreciated by those skilled in the art: 
First, the subject system permits a client and an 
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agent to interact exclusively across a network. Accord- 
ingly, an event affecting only one client is conveyed to 
that one client rather than a group of clients on the net- 
work. Accordingly, the amount of "traffic" on the network 
is minimized. 

Second, the client and agent interact cooperatively 
to facilitate the above-mentioned exclusivity. More par- 
ticularly, the client provides a server with a suffix object 
identifier ("OID") and, when a selected event occurs, 
that suffix OID is combined with a prefix OID, maintained 
by the agent, so that a resultant OID, particular to the 
client, is created. In turn, the resultant OID is used to 
obtain a trap that is provided to just the client. 

Third, the suffix OlDs are made available to the 
server in a convenient manner. In one example, a suffix 
OID is embedded in a comment section of a job ex- 
pressed in a page description language. In this way the 
suffix OID can be stripped readily from from the job dur- 
ing parsing at the server. 

Finally, the OlDs can be configured so that a client 
is provided with a specific indication regarding a job with 
which a given trap is associated. In this way, the client 
is not forced to conjecture to which job a given trap be- 
longs. 



Claims 

1 . A system for automatically transmitting a set of in- 
formation to a selected one of first and second cli- 
ents in a printing system including a printing ma- 
chine associated with a plurality of subsystems and 
being operatively coupled with a server, the server 
communicating with both the first client and the sec- 
ond client, via a network connection, comprising : 

an agent operatively associated with the server, 
for maintaining information regarding the plu- 
rality of subsystems, said agent communicating 
with both the first and second clients; 
a registration system, including the first client, 
the second client and said agent., for registering 
the information, the information including a first 
identifier and a second identifier, the first and 
second identifiers being stored with the agent 
and corresponded with first and second sets of 
information, respectively; and 
said agent transmitting the first set of informa- 
tion exclusively to said first client when a first 
event occurs in one or more of the plurality of 
subsystems and transmitting a second set of in- 
formation exclusively to the second client when 
a second event occurs in one or more of the 
plurality of subsystems. 

2. The system of claim 1 , wherein the first client is 
adapted to generate a print job, expressed in a page 
description language, and the first identifier is em- 
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bedded in the page description language of the print 
job. 

3. The system of claim 2, including means for trans- 
mitting the print job from the first client to the server 
and means for stripping the first identifier from the 
page description language of the print job. 

4. The system of claim 1, 2 or 3, in which the server 
includes a print process for controlling of jobs, the 
first identifier is associated with a print job and the 
first event comprises a completion of the print job, 
wherein in accordance with said print process the 
server is adapted to transmit the first identifier from 
a data store, associated with the server, to the 
agent. 

5. The system of any of claims 1 to 4, in which each 
of the first identifier and second identifier include a 
first identifier portion and a second identifier portion, 
wherein: 

the first identifier portions are provided, by the 
first and second clients, to the server; and 
the first identifier portion of the first client is 
combined with one of the second identifier por- 
tions when the first event occurs and the first 
identifier portion of the second client is com- 
bined with one of the second identifier portions 
when the second event occurs. 

6. The system of any of the preceding claims, in which 
the first identifier is part of a first object identifier and 
the second identifier is part of a second object iden- 
tifier, the agent being configured with simple net- 
work management protocol software such that the 
first object identifier corresponds to a first trap and 
the second object identifier corresponds to a sec- 
ond trap, the first trap and the second trap compris- 
ing the first set of information and the second set of 
information, respectively. 

7. A system for informing a client, with a server, that 
an event associated with one of a plurality ol print- 
related functions has occurred in a printing system 
for performing the plurality of print-related functions 
and including the server communicating with the cli- 
ent by way of a network connection, the client being 
under control of a user, comprising: 

an agent operatively associated with the server, 
a first identifier portion being stored at said 
agent; 

a source of identifier portions, said source pro- 
viding a second identifier portion; 
a storage device, communicating with said 
source, for storing the second identifier portion; 
process means, associated with one of the 
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print-related functions, for conveying the sec- 
ond identifier portion to said agent when the 
event occurs; 

in response to receiving the second identifier, 
said agent being adapted to combine the sec- s 
ond identifier portion with the first identifier por- 
tion to form a resultant identifier, the resultant 
identifier corresponding with a packet of infor- 
mation indicating that the event has occurred; 
said agent being adapted to transmit the packet to 
of information to the client; 
in response to receiving the packet of informa- 
tion, the client being adapted to inform the user 
of the occurrence of the event by reference to 
the information of the packet received at the cli- is 
. ent. 

8. The informing system of claim 7, wherein said 
source comprises an identifier generator for gener- 
ating the second identifier portion. 20 

9. A method of informing a client with an agent, of the 
occurrence of an event in a printing system, includ- 
ing a server communicating with the client by way 

of a network connection, the server including the 25 
agent, at which a first identifier portion is stored, 
wherein the agent is apprised of an occurrence of 
an event and the event is associated with a function 
of the printing system, comprising: 

30 

providing a second identifier portion to the serv- 
er; 

conveying the second identifier portion to the 
agent when the event occurs; 
combining the second identifier portion and the 35 
first identifier portion, with the agent, to form a 
resultant identifier, the resultant identifier cor- 
responding with a packet of information indicat- 
ing that the event has occurred; 
transmitting the packet of information to the cli- 40 
ent; and 

in response to receiving the packet of informa- 
tion, informing the user of the occurrence of the 
event by reference to the packet of information. 

45 

10. A method for automatically transmitting a packet of 
information to a selected one of first and second cli- 
ents in a printing system including a printing ma- 
chine associated with a plurality of subsystems, the 
printing machine being operatively coupled with a so 
server, the server communicating with both the first 
client and the second client, via a network connec- 
tion, the server including an agent for maintaining 
information regarding the plurality of subsystems, 
comprising: 55 

transmitting a first identifier from the first client 
to the server, and a second identifier from the 



second client to the server; 
registering both the first and second identifiers 
with the agent so that the first identifier is cor- 
responded with a first packet of information and 
the second identifier is corresponded with a 
second packet of information; and 
when one of the plurality of subsystems causes 
a first event to occur, transmitting the first pack- 
et of information exclusively to the first client, 
and when another one of the plurality of sub- 
systems causes a second event to occur, trans- 
mitting the second packet of information exclu- 
sively to the second client. 



12 



EP 0 749 065 A1 



16 



14 



Network 
Service 
Module 



■N 

V 



Video Control Module 
(VCM) 



12 



10 



Scanner 



Printer 



FIG. 1 



38. 



40 



r 




Packet Buffer 


VBus 


DMA 


Interface 


Transfer Unit 




J 



36 



-42 




FIG. 3 



owerw^in- ,cd r>*7 a oar k a 1 i *. 



13 




14 




15 



EP 0 749 065 A1 



r ~ ~ ~ ~ ~ — -z: 



Application(s) 
^110 



108 



v 



i 



Emitter 



84 



Event Handling 
Subsystem 



114 



► 



I 



Print 
Manager 



12 



SNMP 
Subsystem 



702 



Mass 
Memory 



Transport 
Provider 



-106 



104 



1 



LPT 
Port 



~1 



To LAN 

FIG. 6 



16 




EP 0 749 065 A1 



136 



Initiate 
"Listening" 
Routine for ID(s) 



i 



Register ID(s) in 
Configuration 
Arrangement 
of Agent 



"\ 138 



Q Return ^ 




Yes 



1 



122 



Generate Job 
without 
Identifier ("ID") 



Obtain Network 
Unique ID (s) 

* 



Generate Job 
Expressed in PDL 
Description 



Embed ID(s) in 
PDL Description 



-124 



-126 



-128 



Transmit Job to 
Print Manager 

T 



-130 




FIG. 7 



17 



EP 0 749 065 A1 



i 



140 



Via Connectivity Layer 









Document 


< ► 




Manager 




• 
• 
• 




752 





156 



XT 



ISO 



Subsystem Processes: 



Imaging 



Marking 



Finishing 



Diagnostics 




To LAN 



FIG. 8 



( Get Job 



164 





t 


Interpert Job and Strip 
ID from Comments of 
PDL Description 




r 


Generate Job Attributes 

and Associate ID with 
one of the Job Attributes 




f 



c 



Store Job Attributes 
in Data Store 



■166 



-168 



■170 



FIG. 9 



18 



% 



EP 0 749 065 A1 



794 



> — 



Prefix OID II Suffix OID 



Application OID 

FIG. 10 



Q Event Occurs y^^174 



Subsystem Process Associated 
with Event ("Subsystem") Detects 
Occurence of Event and Requests 
OID Suffix from DM 



DM Retrieves OID Suffix from 
Data Store and Transmits It to 
Subsystem 



176 



Subsystem Receives OID Suffix 
and Transmits It to Agent 



Agent Combines Suffix with a 
Prefix to form an 
OID Resultant 



Agent Transmits Trap f in the 
form of a "Packet", to SNMP 
Subsystem 



SNMP Subsystem Decodes 
Contents of Packet and Conveys 
Decoded Information to 
Application 



178 



180 



182 



184 



188 



(Cleanup Operations ^V^^ 790 
Perfromed 

FIG. 11 



19 



EP 0 749 065 A1 



European Patent 
Office 



EUROPEAN SEARCH REPORT 



Application Number 

EP 96 30 4392 



DOCUMENTS CONSIDERED TO BE RELEVANT 



Category 



Citation of document with indication, where appropriate, 
of relevant passages 



Relevant 
to claim 



CLASSIFICATION OF THE 
APPLICATION (Int.CI.6) 



EP-A-0 653 700 (FUJITSU LTD) 17 May 1995 

* figures 1,2,21,23-25 * 

* figures 28,29,33,37 * 

* figures 38,39,49,55 * 

* column 7, line 55 - column 11, line 26 * 

* column 23, line 35 - column 29, line 19 



1-10 



G06F3/12 



column 3G, line 21 
column 35, line 51 



column 31, line 9 * 
column 39, line 22 



EP-A-0 529 818 (XEROX CORP) 3 March 1993 
* the whole document * 



1-10 



TECHNICAL FIELDS 
SEARCHED (bt.CI.6) 



G06F 



The present search report has been drawn up for all claims 



Place af tcardi 


Date or CMOpMion of the icarch 


EUUKT 


THE HAGUE 


27 September 1996 


Weiss, P 



CATEGORY OF CITED DOCUMENTS 

X : particularly relevant if taken alone 

V ; particularly relevant if combined with another 

document of the same category 
A : technological background 
O : non-written disclosure 
P : intermediate document 



T : theory or principle underlying the invention 
E : earlier patent document, but published do, or 

after the filing date 
U : document cited io the application 
I. : document cited for other reasons 

& : member of the same patent family, corresponding 
document 



20 



